1. Field of the Invention
The present invention is related to the field of network telephony, and more specifically to devices, softwares and methods for accelerating the setup of a network telephone call.
2. Description of the Related Art
Networks such as the internet are increasingly used for telephony. Prior to actually speaking on the telephone, the end devices are engaged in setting up the telephone call. The process of setting up takes place by exchanging signals, as dictated by an appropriate protocol.
More generally, a number of applications run above the Internet Protocol (IP) layer. Such applications include multimedia applications, as for example Voice over IP (VoIP). Network telephony takes place under VoIP.
Each telephone call is made by two complementary voice streams between the two end devices. Admission control for such applications is supported through the use of RSVP signaling and RSVP admission control. For example, setting up the call could involve setting up two RSVP sessions, i.e., one RSVP session for each of the two voice streams. “RSVP” stands for “Resource Reservation Protocol”, and is also known as “Resource Reservation Setup Protocol”. It is a protocol that supports the reservation of resources across an IP network. Applications running on IP end systems can use RSVP to indicate to other nodes the specification of the packet streams they want to receive. The specification involves bandwidth, jitter, maximum burst, port number, and so forth of the packets.
RSVP signaling takes place during application session establishment, which in the case of VoIP is during call setup. RSVP signaling must be synchronized with the application session establishment phase, which in the case of VoIP is with Voice signaling call flow. This is necessary to ensure compatible behavior from the end user.
This must take place fast. In the case of VoIP, RSVP signaling must happen early enough in the VoIP signaling call flow, so that RSVP admission control can take place before the telephone of the called party rings. To constrain matters even more, since RSVP is unidirectional, it must be initiated by each one of the two parties to the prospective exchange. But RSVP signaling can only take place once sufficient information about the session is known to each side about the other.
Two examples of this type of information that needs to become known are now discussed.
First, in the particular case of the International Telecommunications Standard (ITU) as H.323 version 3, section ITU-T SG16 specifies one approach for synchronizing RSVP signaling with H.323 signaling. This approach has the purpose of, among others, negotiating the required level of Quality of Service (QoS). For this purpose, the called party is required to convey to the calling party some information before the caller can initiate RSVP signaling. The information is conveyed through H.323 signaling messages, and relates to a number of attributes for the session associated by the called party.
The H.323 signaling messages have at least two fields. A first field is sometimes called QoScapabilities, and includes the bandwidth, the burst size, etc. A second field is sometimes called OpenLogicalChannel field, and includes a subfield called the H2250LogicalChannelParameters. The latter includes the port numbers used.
Referring to FIG. 1, a signaling sequence 100 shows salient portions of ITU Standard H.323. Sequence 100 may be used for exchanging messages (also known as signals) that contain such information.
In FIG. 1, an originating device OD calls a terminating device TD by sending a message 110. Message 110 is also known as Q.931 Setup with fastStart.
Terminating Device TD then responds with messages 120 and 130. Message 120 is also known as Q.931 CallProceeding with fastStart, and includes information as to how device TD is to be accessed. Message 130 is also known as RSVP Path, and includes information as to how device TD will be accessing.
Originating Device OD then has enough information to initiate the RSVP session. Device OD then responds with messages 140 and 150. Message 140 is also known as an RSVP Resv (reservation) signal. Message 150 is also known as RSVP Path, and is reciprocal to message 130.
The second example is with the relatively new, so-called Session Initiation Protocol (SIP). Under SIP there is a QoS precondition establishment, where the called party has to convey information to the calling party. This is conveyed by an SIP signaling message under 183 Session Progress. The message includes an SDP which contains information on the session attributes necessary for the calling party to initiate the RSVP session with the called party.
A complexity is with the H.323 CallProceeding message and the equivalent SIP 183 message. They are both optional and many vendors might not implement them in the first place. Because they constitute additional steps in the call flow and thus increase call establishment time, these signaling messages may need to be avoided in some environments which require very fast call establishment. Yet other application protocols might not include at all an equivalent of the CallProceeding message. Then the attributes do not become known, or other arrangements are necessary.